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METHODE D'AUTHENTIFICATION DUPLICATIONS 



La presente invention concerne le domaine de la telephone mobile appelee ausj 
telephone cellulaire. Elle concerne plus particulierement I'authentification duplication 
fonctionnant sur un appareil portable connecte a un module de securite associe a u 
5 equipement mobile de telephonie mobile. 

Le module de securite d'un telephone mobile ou portable est connu sous I'appellatioi 
"carte SIM" (Subscriber Identification Module) constituant ('element central de li 
securite de ces telephones. L'operateur de telephonie introduit, a la fabrication et/oi 
lors d'une phase de personnalisation, un numero appele IMSI (International Mobile 

0 Subscriber Identity) servant a identifier d'une maniere sure et unique chaque abonne 
desirant se connecter sur un reseau mobile. De plus, chaque telephone mobile, appek 
- -equipement mobile ci-apres, est identifie par un numero unique stocke dans une" 
memoire non volatile de I'equipement mobile. Ce numero, appele IMEI, (International 
Mobile Equipment Identity) sert a identifier un equipement mobile donne sur un reseau 

5 du type GSM (Global System for Mobile communications), GPRS (General Packet 
radio Service) ou UMTS (Universal Mobile Telecommunication System). Le meme 
concept ^identification s'appOque egalement au WLAN (Wireless LAN) ou au cable TV 
bidirectionnel. L'identifiant peut §tre une adresse MAC (Media Access Control) qui 
correspond a I'adresse unique identifiant la configuration du materiel d'un utilisateur 
connects & un reseau. 

Les normes ETSI ("European Telecommunications Standards Institute"), definissent 
une station mobile (MS, mobile station) composee d'un equipement mobile (ME, 
mobile equipment) et d'un module d'abonne (SIM, subscriber identity module). Ce 
module d'abonne est -en-geneTalamovible c'est-a-direqu'if peut etresoit retire soit" 
transfere d'un equipement mobile a un autre. 

Lors de la mise en service d'un equipement mobile, plus particulierement lors de sa 
connexion au reseau d'un operateur, des informations comprenant les donnees 
d'identification sont echangees entre I'equipement mobile et le centre de gestion de 
l'operateur qui autorise ou non son utilisation. Actuellement un equipement mobile offre 
a un abonne, en plus de sa fonction usuelle d'etablissement de conversations 



-2- 



telephoniques, I'utilisation de nombreux autres services supplementaires tels que la 
consultation de diverses informations, les operations bancaires a distance, le 
commerce electronique, etc. Ces services evolues necessitent un niveau de securite de 
plus en plus eleve afin de premunir les utilisateurs contre les fraudes eventuelles 
causSes par des tiers. 

La verification de conformite ou authentication devient done n§cessaire au moins a 
deux niveaux: d'une part au niveau de I'equipement mobile lui-m§me et d'autre part a 
celui des applications logicielles permettant le fonctionnement des differents services 
proposes par I'operateur ou par des partenaires autorises. Ces applications sont en 
general telechargees depuis le serveur d"un fournisseur d'applications, ce qui implique 
la necessite de verifier ce telechargement. II s'agit done de garantir que le module 
d'abonn<§ ne fournit des informations qu'a des applications autorisees une fois que ce 
module a ete reconnu par le serveur de contr6le comme pouvant fonctionner avec 
I'equipement mobile dans lequel il est insere. 

Le module d'abonne peut contenir des informations confidentielles tels qu'un numero de 
compte bancaire ou un mot de passe. Une application fonctionnant sur I'equipement 
mobile sera en charge d'utiliser ces donnees personnels afin de fournir le service 
attendu. Neanmoins, une application pourrait detourner ces donnees personnelles a 
d'autres fins que le dialogue avec le fournisseur duplication concerne. II peut en 
resulter un prejudice important pour le proprietaire du module d'abonne. 

Ces applications executees dans I'equipement mobile utilisent des ressources 
disponibles dans le module d'abonne. Par ressources, on entend diverses fonctions et 
donnees necessaires au bon fonctionnement d'une application. Certaines de ces 
ressources peuvent etre communes a plusieurs applications, notamment les fonctions 
liees a la securite. Le module d'abonn§ peut ainsi bloquer ou plut6t rendre inutilisables 
certaines applications dont les parametres de securite ou les droits de I'utilisateur sont 
insuffisants. 

Le but de la presente invention est de proposer une methode d'authentification de ou 
des applications dans un equipement mobile tant lors de leur telechargement que lors 
de leur execution. 



Un autre but est de proteger I'utilisateur de I'equipement mobile ainsi que Ic 
fournisseurs ^applications concernes centre les abus resultants de Pusag 
d'applications non autorisees. 

Ces buts sont atteints par une methode d'authentification d'au moins une applicatic 
5 fonctionnant dans un appareil connecte par un reseau a un serveur de contrdle, ce 
appareil etant localement connecte a un module de securite, ladite application es 
chargee et/ou executee au moyen d'un environnement d'execution d'applications d« 
I'appareil et utilise des ressources stockees dans le module de securite, cette method 
est caracterisee en ce qu'elle comprend les etapes suivantes: 
1 0 - identification de I'appareil et du module de securite par le serveur de contrdle er 
vue du chargement et/ou de I'execution d'une application, 

- analyse et verification par le serveur de contrdle desdites donnees, 

- preparation d'un cryptogramme comprenant I'identification du module de securite 
et une empreinte de I'application, 

15 - transmission dudit cryptogramme, via le reseau et I'appareil, par le serveur de 
contr6le vers le module de securite, 

- extraction de Fempreinte, inciuse dans le cryptogramme par le module de 
securite, 

- lors de Initialisation d'une application, determination de I'empreinte de ladite 
application et oomparaison de cette empreinte avec I'empreinte stockee dans le 
module de securite, 

- liberation, respectivement blocage, de I'acces a certaines ressources du module 
de securite en fonction du resultat de la verification de I'empreinte propre a cette 
application. 

Cette methode s'applique de preference-a" ia~t§liphonie" mobile/ Par cons^ 
I'appareil est un equipement mobile telephonique et le module de securite un module 
d'abonne ou carte SIM. Cet ensemble se connecte a un reseau mobile du type GSM 
(Global System for Mobile communications), GPRS (General Packet Radio Service), 
UMTS (Universal Mobile Telecommunications System), WLAN (Wireless Local Area 
Network) ou autre, gere par un serveur de contrdle d'un operateur. Des applications 
logicielles sont instates dans I'equipement mobile et configurees de maniere a utiliser 
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des ressources (donnees ou fonctions) presentes dans le module d'abonne. Elles ne 
peuvent done etre utilises dans leur integrate seulement si les conditions de securites 
sont satisfaites selon des criteres preetablis par I'operateur ou le fournisseur 
^applications. Ces criteres sont, pour des raisons de securite, verifiables dans le 

5 module de securite et vont definir les regies d'acces aux ressources du module 
d'abonne pour chaque application. Les criteres peuvent se referer, par exemple, a la 
periode de mise a jour des regies d'acces, au nombre de connexions au reseau, la 
technologie utilisee pour I'acces au reseau, I'identite du reseau d'acces utilise, et a 
differents risques associes au materiel ou aux logiciels utilises que I'operateur desire 

1 0 prendre en compte. 

Les ressources du module d'abonne sont bloquees ou liberees de maniere ciblee, ceci 
dans le but de rendre certaines applications utilisables ou non. On ne bloque pas ou 
libere pas directement des applications de I'equipement mobile: on agit de maniere 
indirecte sur les applications, e'est-a-dire que I'effet de blocage ou de liberation va se 
15 manifester uniquement lorsque I'equipement mobile essaiera d'executer ces 
applications. 

La methode selon I'invention est basee sur le fait qu'a une application on associe un 
cryptogramme qui conditionne rutilisation de I'application sur un equipement mobile 
connecte a un reseau. 

20 Dans un premier mode de realisation, le cryptogramme est transmis au module 
d'abonne pendant le chargement de I'application. Dans un second mode de realisation, 
e'est I'application qui va chercher le cryptogramme sur le serveur de contrdle lors de sa 
premiere utilisation. 

La methode d'authentification selon I'invention s'applique egalement lors de I'execution 
25 d'une application par I'equipement mobile, ce qui permet de s'assurer, a I'aide du 
module d'abonne, que cette application est autorisee a acceder certaines ressources 
(donnees ou fonctions) contenues dans ledit module d'abonne. En particulier, le module 
d'abonn§ peut verifier regulierement le cryptogramme attache a une application au 
cours de I'execution de ladite application. 



Par exemple, I'insertion d'un module d'abonne d'un utilisateur dans un autre equipemer 
mobile influencera le fonctionnement de certalnes applications sans empeche 
I'etablissement de communications telephoniques classiques. Cette barriere agit er 
quelque sorte comme un filtre visant a eliminer des equipements mobiles ou de 
appareils de simulation non autorises ou encore des applications provenant de source, 
non agreees par I'operateur. 

Une modification de Implication par un tiers est egalement detectee par le module 
d'abonne qui refusera d'executer certaines commandes recues entramant ainsi le 
blocage ou des limitations de I'execution de I'application. 

Le serveur de contrdle joue done un r6le essentiel en gerant les elements de confiancc 
ou de security lies a Pensemble equipement mobile/module d'abonne. II interprets les 
donnees qui lui sont transmises par I'equipement mobile afin de contrdler ou limiter 
I'utilisation d'applications grace aux ressources (donnees ou fonctions) stockees dans 
le module d'abonne. 

La verification du cryptogramme peut s'effectuer lors du premier demarrage ou lors de 
la premiere utilisation d'une application ou a chaque demarrage de celle-ci. Selon une 
variante, elle peut etre executee periodiquement a un rythme donne selon des 
instructions provenant du serveur de controle. 

Lors d'un chargement d'une application dans un equipement mobile, le cryptogramme 
attache accompagnant I'application inclut en general une empreinte de I'application 
elle-meme, e'est a dire un bloc de donnees calcule a partir du code de I'application a 
I'aide d'une fonction mathematique unidirectionnelle de hachage. 

Lorsque le module d'abonne verifie la validife^u~crypt6gramme, il identjfie aussi, de 
maniere indirecte, I'equipement mobile et s'assure que les donnees viennent 
effectivement du serveur de controle. Autrement dit, par ce cryptogramme, le serveur de 
contrdle donne implicitement I'assurance au module d'abonne que I'identificateur de 
I'equipement mobile a ete pris en compte, que le chargement de I'application a ete 
controle et que I'application est authentique. Selon des instructions prealablement 
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regues, le module d'abonne decidera d'autoriser ou de refuser des requetes ou des 
commandes venantde Papplication. 

L'equipement mobile joue un role de relais dans cette etape de verification en 
etablissant un dialogue quasi direct entre le module d'abonne et le serveur de controle. 
5 Ainsi la securite des messages echanges est assuree de bout en bout entre le serveur 
de contrdle et le module d'abonne via I'environnement d'execution des applications de 
l'equipement mobile. Celui-ci ne peutdonc pas "tricher" ou transformer les donnees vis- 
a-vis du module d'abonn6. 

L'invention sera mieux comprise grace a la description detaillee qui va suivre et qui se 
1 0 refere aux figures annexees donnees a titre d'exemple nullement limitatif , a savoir: 

- La figure 1a illustre un schema bloc montrant le processus d'installation d'une 
application selon un premier mode de realisation ou le cryptogramme est deiivre via 
I'environnement d'execution d'applications. 

- La figure 1 b illustre le processus de verification du cryptogramme selon le mode de la 
1 5 figure 1 a. 

- La figure 1c illustre le processus de I'execution de I'application utilisant les ressources 
du module d'abonne selon le mode de la figure 1a. 

- La figure 2a illustre un schema bloc montrant le processus d'installation d'une 
application selon un second mode ou I'application seule est telechargee. 

20 - La figure 2b illustre le processus de verification ou I'application sollicite un 
cryptogramme aupres du serveur de controle selon le mode de la figure 2a. 

- La figure 2c illustre le processus de I'execution de I'application utilisant les ressources 
du module d'abonn§ selon le mode de la figure 2a. 

- La figure 3a illustre un schema bloc montrant le processus d'installation d'une 
25 application selon un troisieme mode ou I'application seule est telechargee. 



La figure 3b illustre le processus de verification ou I'application sollicite u 
cryptogramme et une empreinte de I'application aupres du serveur de controle selon I 
mode de la figure 3a. 

La figure 3c illustre le processus de I'execution de I'application utilisant les ressource? 
du module d'abonne selon le mode de la figure 3a. 

- La figure 4 illustre la structure d'un exemple de cryptogramme. 

Les schemas blocs des figures 1 a, 1 b, 1 c, 2a, 2b, 2c, 3a, 3b, 3c montrent un ensembfc 
equipement mobile (CB) module d'abonne (SIM) contenant des ressources (RES) relK 
via un reseau mobile (NET) a un serveur de contr6le (CSE) administre par ur 
operateur. Ce serveur est connecte a un ou plusieurs fournisseurs d'applications (FA). 

L'equipement mobile (CB) inclut une ou plusieurs applications logicielles (APP) 
fonctionnant dans un environnement d'execution (AEE). Ces applications proviennent, 
soit du fournisseur d'applications (FA) associe au serveur de controle (CSE) de 
I'operateur, soit elles peuvent etre programmers d'origine par le fabricant de 
l'equipement mobile. Dans ce dernier cas, il est parfois necessaire de telecharger des 
mises a jour qui sont egalement verifiees par le module d'abonne (SIM). 

Selon le premier mode de realisation illustre par les figures 1a, 1b, 1c, le cryptogramme 
(CRY) d'une application (APP) est delivre au module d'abonne (SIM) via 
I'environnement d'execution d'applications (AEE) lors du processus d'installation de 
I'application (APP). 

La figure 1a illustre le processus d'installation ou l'equipement mobile (CB) transmet 
d'abord des donnees servant a ('identification (ID) du_module_d'abonne (SIM) que le 
serveur de contr6le (CSE) verifie. Cette identification (ID) est effectuee a partir du 
numero du module d'abonne (IMSI) et elle peut aussi tenir compte du numero unique de 
l'equipement mobile (IMEI). Une application (APP) est ensuite telechargee depuis le 
serveur (CSE) accompagnee d'un cryptogramme (CRY) qui sera transmis vers le 
module d'abonne (SIM) via I'environnement d'execution (AEE) pour verification comme 
illustre dans la figure 1 b. 
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II est a noter que le fournisseur (FA) est consider^ comme digne de confiance par 
I'operateur, c'est-a-dire que les applications (APP) sont homologuees et fonctionnent 
sans causer un quelconque prejudice a I'utilisateur et/ou a I'operateur. 

La methode selon I'invention s'applique a plusieurs formes d'applications (APP) 
5 executees dans differents types d'environnement d'execution (AEE). Par exemple, de 
nombreux telephones mobiles possedent des fonctionnalites issues d'applications Java 
qui sont executees par une machine virtuelle (VM) Java servant de processeur et 
d'environnement. La description ci-apres se base sur I'exemple d'applications Java. 
Bien entendu, d'autres environnements ou systemes d'exploitations tels que Symbian 
0 OS, Windows, Palm OS, Linux embarque etc. peuvent etre utilises comme support 
d'applications. 

~ Lots de son execution, voir figure 1c, une application Java sollicite le module d'abonni 
(SIM), elle en informe I'environnement d'execution (AEE) en lui adressant des requites 
ou commandes (CMD). L'environnement d'execution (AEE) calcule I'empreinte (FIN2) 

5 de rapplication et I'envoie au module d'abonne (SIM). Le cryptogramme (CRY) qui a 
ete gen§r6 par le serveur de controle (CSE) puis charge dans I'equipement mobile 
(CB) avec I'application (APP) (ou separ6ment), est stocks dans le module d'abonne 
(SIM). Ce dernier verifie d'aboid qu'il possede effectivement les donnees necessaires 
lui permettant de decider s'il doit repondre a des requites ou commandes (CMD) de 

20 rapplication (APP). Ces donnees, faisant office de droits charges a partir du serveur de 
contrdle (CSE) lors du chargement de I'application (APP), permettent de contrdler le 
fonctionnement de I'application f/KPP). En cas d'absence de ces droits, I'application 
(APP) ne pourra utiliser les ressources (RES) (donnees ou fonctions) du module 
d'abonne (SIM). 

25 Dans le cas oil ces droits sont presents, le module d'abonni (SIM) verifie I'empreinte 
(FIN1) issue du cryptogramme (CRY) stocke en la comparant avec I'empreinte (FIN2) 
associee a I'application (APP) et fournie par l'environnement d'application (AEE). Ce 
cryptogramme (CRY) peut se constituer sous la forme d'un bloc encrypts par une cl6 
privee du type RSA (Rivest, Shamir, Adelman). Ce bloc represents par la figure 4 

30 contient par exemple, entre autres donnees, I'identificateur du module d'abonne IMSI 
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(ID_SIM), I'identificateur de I'equipement mobile IMEI (ID_CB), un identificateur d 
('application (ID_APP), I'empreinte de ('application (FIN1), des identificateurs de 
ressources SIM (RESJD) et des instructions de blocage/liberation des ressources Sir 
(INS_RES). Cette cle privee ne serait connue que du serveur de contrdle (CSE), alor 
5 que sa partie publique serait connue du module d'abonne (SIM), favantage d 
I'utilisation de cles asymetriques reside en ce que la cle servant a creer de 
cryptogrammes ne se trouve pas a I'exterieur du serveur de controle (CSE). 

Bien entendu, d'autres algorithmes a cles asymetriques teb que par exemple DS/ 
(Digital Signature Algorithm), et ECC (Elliptic Curve Cryptography) peuvent constitue 
1 0 des alternatives a RSA 

L'usage d'algorithme a cles symetriques peut etre prefere pour des raisons de 
simplicite, de rapidite des verifications ou de coOts de fabrication et de mise en oeuvrc 
plus faibles. Dans ce cas, la cle serait connue du serveur (CSE) et du module d'abonnd 
(SIM), par exemple un algorithme IDEA (International Data Encryption Algorithm; 
pourrait etre utilise pour signer le bloc (IMSI, IMEI, identificateur de Implication! 
empreinte de I'application, identificateurs des ressources SIM, instructions de 
blocage/liberation des ressources SIM). Comme alternative a I'algorithme IDEA, des 
algorithmes tels que, par exemple, TDES (Triple Data Encryption Standard) et AES 
(Advanced Encryption Standard) peuvent aussi etre utilises. 

Dans ces deux variantes a cles asymetriques et symetriques, le module d'abonne (SIM) 
verifie la concordance des differents champs apparaissant dans le cryptogramme 
(CRY), notamment il controle les identificateurs d'applications (ID_APP) et les 
empreintes d'applications (FIN1) qui sont autorisees ou non a utiliser ses ressources 
(RES) (donnees ou fonctions). - — 



15 
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Dans une variante, le cryptogramme (CRY) peut inclure un compteur servant a 
empecher le double usage d'un meme cryptogramme adresse au module d'abonne 
(SIM) (replay attack). En effet deux applications du meme type peuvent porter le meme 
identificateur et avoir la meme empreinte (FIN1). Dans ce cas, le module d'abonne 
(SIM) controlera aussi la valeur de ce compteur par comparaison avec celle d'un 
30 compteur de reference stocke et regulierement mis a jour. 
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Une variante au compteur est d'utiliser un alea (nombre aleatoire) genere par ie module 
d'abonne (SIM). Cet alea est transmis avec les donnees envoyees au serveur de 
controle (CSE). Ce dernier renvoie cet alea dans le message de reponse et le module 
d'abonne peut verifier qu'il s'agit bien d'un nouveau message. Plus generalement, afin 
5 d'eviter tout risque d'usage d'un ancien cryptogramme (CRY), cette derniere comprend 
une variable predictible par le module d'abonne (SIM), sort un compteur ou un alea. 

Dans une autre variante le cryptogramme (CRY) genere a I'aide d'une cle du type RSA 
ou IDEA peut etre remplacee par un bloc genere avec une cle partagee HMAC (Keyed- 
Hashing for Message Authentication) a partir de I'ensemble (IMSI, IMEI, identificateur 
10 de I'application, empreinte de I'application, identificateurs des ressources SIM, 
instructions de blocage/liberation des ressources SIM). HMAC est un mecanisme pour 
Tauthentification de messages par I'utilisation de fonctions de hachage 
cryptographiques telles que MD5 (Message Digest) ou SHA-1 (Secure Hash 
Algorithm), en combinaison avec une cle partagee. 

15 Cette cle presente a a fois dans le serveur de controle (CSE) et dans le module 
d'abonne (SIM) peut etre chargee lors de la personnalisation du module d'abonne (SIM) 
ou lors de Installation de certaines ressources (RES) dans le module d'abonne (SIM). 
Selon les options, a chaque ressource (RES) ou groupe de ressources du module 
d'abonne (SIM) peut etre associee une cle differente, ou bien, la cle peut etre globale 

20 pour I'ensemble des ressources (RES) et unique pour un module d'abonne (SIM) 
donne. 

Le cryptogramme (CRY) permet ainsi au module d'abonne (SIM) de connattre la ou les 
ressources (RES) pouvant etre liberees ou bloquees dans le module d'abonne (SIM) 
pour I'equipement mobile (CB) correspondant. 

25 Les deux empreintes utilisees (FIN1, respectivement FIN2) sont des elements 
determinants car elles constituent un moyen de contrdle cryptographique de 
I'application (APP) par I'equipement mobile (CB) et par le module d'abonne (SIM). Un 
tel controle est necessaire afin d'empecher qu'une application tierce s'authentifie avec 
un cryptogramme (CRY) donne. En effet, si le cryptogramme A authentifie I'application 

30 A aupres du module d'abonne A dans un equipement mobile A, il faut eviter qu'une 



autre application B s'authentifie indOment avec ce meme cryptogramme A aupres d 
module d'abonne A dans I'equipement mobile A 



0 



Selon une variante, I'empreinte de I'application (FIN1) incluse dans le cryptogramm, 
(CRY) reste confidentielle de bout en bout entre le serveur de contr6le (CSE) et l< 
module d'abonne (SIM). Pour ce faire I'empreinte (FIN1) est encryptee par le serveur d, 
controle (CSE) et decryptee par le module d'abonne (SIM). De plus, I'application (APP 
peut etre personnalisee pour un chargement donne de maniere a ce que I'empreinte 
(FIN1) incluse dans le cryptogramme (CRY) et I'empreinte (FIN2) de I'application (APP 
calculee par I'environnement d'execution (AEE) restent identiques mais dependent de 
I'identite de I'equipement mobile (CB). Une telle mesure est necessaire si I'on desire 
empecher qu'une application tierce s'authentifie avec une empreinte donnee dans un 
autre environnement d'execution d'applications (AEE) dont I'interface avec le module 
d'abonne (SIM) serait compromise. En effet, si I'empreinte A authentifie I'application A 
aupres du module d'abonne A dans un equipement mobile A, il faut eviter qu'une autre 
application B s'authentifie indOment avec cette meme empreinte A aupres du module 
d'abonne B dans I'equipement mobile B. 

Selon une autre variante, chaque application (du type Java) est accompagnee de deux 
cryptogrammes: un cryptogramme Java destine a la machine virtuelle (VM) et un 
cryptogramme (CRY) destine au module d'abonne (SIM). Ces deux cryptogrammes 
comprennent entre autre la meme empreinte d'application (ici appelee FIN2) qui est 
celle du code de I'application Java. Ainsi, lorsque le module d'abonne (SIM) doit verifier 
le cryptogramme (CRY) d'une application, il attend de la machine virtuelle (VM) 
I'empreinte (FIN2) associee a I'application (APP) en question qu'elle aura forcement 
calculee auparavant. L'empreinte de I'application est transmise par I'equipement 
mobile (CB) au module d'abonne (SIM). Cette empreinte ne provient pas du serveur de 
controle, elle est calculee par I'environnement d'execution d'applications (AEE) de 
I'equipement mobile (CB) apres le telechargement de I'application (APP). Par contre, 
I'equipement mobile (CB) transmet le cryptogramme (CRY) prealablement charge en 
sus de I'application depuis le serveur de contr6le au module d'abonne. Ainsi, ce dernier 
peut verifier I'empreinte recue par comparison. Uequipement mobile (CB) ne peut pas 
tricher tant qu'il ne connaTt pas I'empreinte attendue par le module d'abonne (SIM); le 
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cas echeant, cela necessiterait de rendre la fonction de calcul de I'empreinte, 
habituellement une fonction de hachage, reversible ou de trouver une autre empreinte 
donnant le meme cryptogramme (CRY) ce qui est quasiment impossible. 

La figure 1b montre le processus de verification du cryptogramme (CRY) qui peut 
5 s'effectuer soit regulierement, par exemple avant chaque sollicitation de l'application 
(APP) concernee, soit, de preference, une seule fois avant son installation ou avant sa 
premiere utilisation. Si le cryptogramme (CRY) est valide, le module d'abonne (SIM) 
transmet un message d'acceptation (OK) a I'environnement d'execution (AEE). 
L'application (APP) peut alors adresser ses requetes ou commandes (CMD) au 
1 0 module d'abonne (SIM) via I'environnement d'execution (AEE) et utiliser les ressources 
(RES) du module d'abonne (SIM). Ce dernier accepte les commandes (CMD) en 
transmettant les reponses (RSP) adequates a l'application (APP) via I'environnement 
d'execution (AEE), voir figure 1c. 

Dans le cas d'un cryptogramme (CRY) non valide, le module d'abonne (SIM) transmet 
15 un message de refus (NOK) a I'environnement d'execution (AEE). Dans un tel cas 
I'environnement d'execution (AEE) peut soit annuler le processus ^installation de 
l'application (APP), soit l'application (APP) est installee et ses requetes ou ses 
commandes (CMD) adressees au module d'abonne (SIM) via I'environnement 
d'execution (AEE) resteront sans reponse (RSP) et les ressources (RES) du module 
20 d'abonne (SIM) ne pourront etre utilisees. 

Dans les deux cas d'acceptation et de refus (OK et NOK) I'environnement d'execution 
d'application (AEE) peut relayer la reponse au serveur de contr6le (CSE). Le module 
d'abonne peut ainsi indirectement renvoyer une confirmation (CF) de reception du 
cryptogramme (CRY) au serveur de contrSle (CSE) et permettre un controle de bout en 
25 bout de I'operation, voir figure 1 b. La confirmation (CF) comprend au moins un code de 
succes ou d'erreur de I'operation ainsi qu'un compteur servant a la protection contre 
des attaques par repetition. Ce message permet aussi au serveur de controle (CSE) 
de tenir a jour le compteur associe au module d'abonne (SIM). 
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Selon le second mode de realisation illustre par les figures 2a, 2b, 2c, I'applicatio 
(APP) est telechargee seule, apres identification (ID) de I'equipement mobile (CBJ 
sans cryptogramme (CRY), voir figu re 2a. 

Lors du processus de verification, figure 2b, ('application (APP) sollicite, lors de soi 
lancement par Puflisateur, un cryptogramme (CRY) comprenant les droits d'utilisatioi 
de ressources (RES) pour ladite application. Ce cryptogramme (CRY) est telecharg^ 
depuis le serveur (CSE) de contr6le, directement par ('application (APP) qui le transme 
au module d'abonne (SIM) via I'environnement d'execution (AEE). Le module d'abonne 
(SIM) transmet une confirmation (CF) de reception du cryptogramme (CRY) au serveu 
(CSE), par le biais de ('application (APP) et non par le biais de I'environnemen 
d'execution (AEE) comme dans le cas du premier mode de realisation. Dans ce mode 
I'environnement d'execution (AEE) ne joue qu'un r6le de relais entre ('application (APP] 
et le module d'abonne (SIM). 

Le processus d'execution de ('application (APP) apres verification du cryptogramme 
(CRY), voir figure 2c, se deroule de la meme maniere que dans le premier mode illustre 
par la figure 1 c et decrit plus haut. 

Les figures 3a, 3b, 3c montrent une troisieme variante ou implication APP est 
telechargee seule, apres identification (ID) de I'equipement mobile (CB), depuis le 
serveur de contr6le (CSE) ou depuis un serveur intermediate de telechargement 
d'applications (APP) voir figure 3a. Lors du processus de verification (figure 3b), 
('application charge le cryptogramme (CRY) et I'empreinte (FIN2) directement a partir 
du serveur (CSE) ou depuis un serveur intermediate de telechargement d'applications 
(APP). Dans ce cas, a la difference des deux variantes precedentes, I'environnement 
duplication (AEE) ne calcule plus l'em P Teinte-(FIN2) quresrcalcul^e par une unite 
externe soit par le serveur de contrdle CSE, sort par un serveur intermediate de 
telechargement d'applications (APP). 

Le processus d'execution de Implication (APP) apres verification du cryptogramme 
(CRY), voir figure 3c, se deroule de la meme maniere que dans les deux modes 
precedents illustres par les figures 1 c et 2c. 
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Ce troisieme mode de realisation peut etre prefere car son avantage est de ne 
demander aucune modification de I'environnement d'execution (AEE) tel qu'il est defini 
actuellement pour les applications Java installees dans les telephones mobiles, c'est-a- 
dire qu'une modification des normes existantes n'est pas necessaire. 

De plus, la contrainte de la premiere variante voulant que les deux cryptogrammes 
utilisent la meme empreinte tombe etant donne que les processus de verification du 
cryptogramme (CRY) et celui de ('installation de l*application sont totalement 
independants. 

Afin de personnaliser les empreintes calculees sur les applications, une possibility 
consiste a ajouter au code de ['application, avant son chargement dans I'equipement 
mobile, une donnee differente pour chaque equipement mobile. Ainsi, lorsque 
fempreinte est calculee par I'environnement ^application de I'equipement mobile, cette 
empreinte est unique et ne peut servir a un autre equipement mobile. Le cryptogramme 
va bien entendu etre calcule par le serveur de contrCle sur la base des donnees 
d'origine de ^application et de cette donnee unique. 

Dans une variante de Invention, I'equipement mobile peut etre remplace par un 
appareil non mobile tel qu'un decodeur de television a peage ou un ordinateur. Des 
applications peuvent etre telechargees dans I'appareil a partir d'un serveur via un 
reseau de telecommunications. Un cryptogramme associe a I'application est stocke 
dans le module de securite et verifie lors de la mise en service ou lors de chaque 
demarrage d'une application. Le r6sultat de cette verification conditionne le 
fonctionnement de I'application en liberant ou en bloquant des ressources dans le 
module de securite. 
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REVENDICATIONS 

1 . Methode d'authentification d'au moins une application (APP) fonctionnant dan 
un appareil connects par un reseau (NET) a un serveur de controle (CSE), cet appare 
etant localement connecte a un module de securite (SIM), ladite application (APP) es 
chargee et/ou executee au moyen d'un environnement d'execution duplications (AEE 
de I'appareil et utilise des ressources (RES) stockees dans le module de security 
(SIM), cette methode est caracterisee en ce qu'elle comprend les etapes suivantes: 

- identification de I'appareil et du module de securite (SIM) par le serveur de 
contr6le (CSE) en vue du chargement eVou de I'execution d'une applicatior 
(APP), 

analyse et verification par le serveur de contrdle (CSE) desdites donnees, 

- preparation d'un cryptogramme (CRY) comprenanUme empreinte del'appllcaHon 
(APP), 

- transmission dudit cryptogramme (CRY), via le reseau et I'appareil, par le serveur 
de contrdle (CSE) vers le module de securite (SIM), 

- extraction de I'empreinte (FIN1), incluse dans le cryptogramme (CRY) par le 
module de securite (SIM), 

- lors de I'initialisation d'une application (APP), determination de I'empreinte (FIN2) 
de ladite application (APP) et comparaison de cette empreinte (FIN2) avec 
I'empreinte (FIN1 ) stockee dans le module de securite (SIM), 

- liberation, respectivement blocage, de I'acces a certaines ressources (RES) du 
module de securite (SIM) en fonction du resurtat de la verification propre a cette 
application (APP). 

2. Methode selon la revendication 1 caracterisee en ce que I'appareil. est un 
equipement mobile (CB) de telephonie mobile. 

3. Methode selon les revendications 1 et 2 caracterisee en ce que le reseau (NET) 
est un reseau mobile du type GSM ou GPRS ou UMTS ou WLAN. 

4. Methode selon les revendications 1 a 3, caracterisee en ce que le module de 
securite (SIM) est un module d'abonne insere dans I'equipement mobile (CB) de 
telephonie mobile de type carte SIM. 
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5. Methode selon les revendications 1 a 4 caracterisee en ce que I'identification 
(ID) du module de securite (SIM) est effectuee a partir d'un numero identifiant ledit 
module de securite (SIM) propre a un abonne au reseau mobile (NET) et a partir d'un 
numero identifiant de maniere unique I'equipement mobile (CB). 

6. Methode selon la revendication 1 caracterisee en ce que le cryptogramme 
(CRY) recu par le module de securite (SIM) conditionne I'utilisation des applications 
(APP) selon des criteres preetablis par I'operateur ou le fournisseur duplications (FA). 

7. Methode selon la revendication 6 caracterisee en ce que les criteres d6finissent 
des limites d'utilisation d'une application (APP) selon des risques associes au logiciel 
de ladite application (APP) ou au materiel de I'equipement mobile (CB) que I'operateur 
desire prendre en compte. 

8. Methode selon les revendications 1 a 7 caracterisee en ce que la verification du 
cryptogramme (CRY) s'effectue lors du premier demarrage ou lors de la premiere 
utilisation d'une application (APP). 

9. Methode selon les revendications 1 a 7 caracterisee en ce que la verification du 
cryptogramme (CRY) s'effectue periodiquement a un rythme donne selon des 
instructions provenant du serveur de contrdle (CSE). 

1 0. Methode selon les revendications 1 a 7 caracterisee en ce que la verification du 
cryptogramme (CRY) s'effectue lors de chaque demarrage d'une application (APP) sur 
I'equipement mobile (CB). 

11. Methode selon les revendications 1 a 10 caracterisee en ce que le 
cryptogramme (CRY) est g6n6re a I'aide d'une cie d'encryption asymetrique ou 
symetrique a partir d'un ensemble de donnees contenant, entre autres donnees, le 
numero ^identification unique de I'equipement mobile (CB), le numero ^identification 
du module d'abonne (SIM), un identificateur de I'application (APP), I'empreinte (FIN1) 
de I'application (APP) calcuiee avec une fonction unidirectionnelle de hachage et des 
identificateurs des ressources SIM (RESJD) et des instructions de blocage/liberation 
des ressources SIM (INS_RES). 
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12. MSthode selon la revendication 11 caracterisee en ce que le cryptogramr™ 
(CRY) comprend une variable predictible par le module d'abonne (SIM) evitant k 
double usage d'un meme cryptogramme (CRY), la valeur de ladite variable etar 
controlee par le module d'abonne (SIM) par comparaison avec celle d'une valeur d< 
reference stockee dans ledit module et regulierement mise a jour. 

13. Methode selon les revendications 1 a 12 caracterisee en ce que le module 
d'abonne (SIM) transmet au serveur de contrdle (CSE), via I'equipement mobile (CB) e 
le reseau mobile (NET), un message de confirmation (CF) lorsque ledit module 
d'abonne (SIM) a accepts ou refuse un ciyptogramme (CRY) d'une application (APP). 

1 4. Methode selon les revendication 1 a 1 3 caracterisee en ce que le cryptogramme 
(CRY) est transmis au module de securite (SIM) en meme temps que I'application 
(APP) est chargee dans I'appareil (CB) via Tenvironnement d'execution des 
applications (AEE). 

15. Methode selon la revendication 1 a 13 caracterisee en ce que I'application 
(APP), une fois chargee dans I'equipement mobile (CB) depuis le serveur (CSE) de 
contrdle via le reseau (NET), sollicite un cryptogramme (CRY) au serveur (CSE) lors de 
son initialisation et transmet ledit cryptogramme (CRY) au module de securite (SIM), le 
message de confirmation (CF) d'acceptation ou de refus du cryptogramme (CRY) etant 
transmis par le module de securite (SIM) au serveur via I'application (APP). 

16. Methode selon la revendication 1, caracterisee en ce que I'appareil est un 
decodeur de television a peage ou un ordinateur auquel est connecte le module de 
securite. 

17. Module de securite comprenanf des "ressources (RES) destine~es~a etre 
localement accedees par une application (APP) executee sur un appareil (CB) relie a 
un reseau (NET), ce module comprenant des moyens de stockage du cryptogramme 
(CRY) et de Tempreinte (FIN1) de ladite application (APP) et des moyens de 
transmission d'un message de confirmation (CF) d'acceptation ou de refus du 
cryptogramme (CRY), caracterise en ce qu'il comprend des moyens de verification du 
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cryptogramme (CRY) et de I'empreinte (FIN1) stockes permettant de liberer ou de 
bloquer certaines ressources (RES) selon le resultat de !a verification. 

1 8. Module de securite selon la revendication 17, caracterise en ce qu'il est du type 
"module d'abonne" ou "carte SIM" destine a etre relie a un equipement mobile. 
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ABREGE 

Le but de la presente invention est de proposer une methode d'authentification 
d'applications tant lors de leur telechargement que lors de leur execution. 

Ce but est atteint par une methode d'authentification d'au moins une application (APP) 
fonctionnant dans un appareil connecte par un reseau (NET) a un serveur de contrdle 
(CSE), cet appareil etant localement connecte a un module de securite (SIM), ladite 
application (APP) est chargee et/ou executee au moyen d'un environnement 
d'execution d'applications (AEE) de I'appareil et utilise des ressources (RES) stockees 
dans le module de securite (SIM), cette methode est caracterisee en ce qu'elle 
comprend les etapes suivantes: 

identification de I'appareil et du module de securite (SIM) par le serveur de 
controle (CSE) en vue du chargement et/ou de I'execution d'une application 
(APP), 

analyse et verification par le serveur de contrdle (CSE) desdites donnees, 
preparation d'un cryptogramme (CRY) comprenant ('identification du module de 
securite (SIM) et une empreinte de I'application (APP), 

transmission dudit cryptogramme (CRY), via le reseau et I'appareil, par le serveur 
de contrdle (CSE) vers le module de securite (SIM), 

extraction de I'empreinte (FIN1), incluse dans le cryptogramme (CRY) par le 
module de securite (SIM), 

lors de I'initialisation d'une application (APP), determination de I'empreinte (FIN2) 
de ladite application (APP) et comparaison de cette empreinte (FIN2) avec 
I'empreinte (FIN1 ) stockee dans le module der securite (SIM), 
liberation, respectivement blocage, de I'acces a certaines ressources (RES) du 
module de securite (SIM) en fonction du resultat de la verification propre a cette 
application (APP). 
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